https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# replication-ask-ai
s
This message was deleted.
k
Thinking completed The knowledge sources do not explicitly mention the exact error message:
Copy code
ERROR unable to determine organization email: failed to get organization: unable to fetch token: unable to decode token request: invalid character '<' looking for beginning of value
However, based on the components of this error, here is what is occurring and how to address it: What the Error Means 1. HTML Returned Instead of JSON: The error 
invalid character '<' looking for beginning of value
is a standard parsing error indicating that the client (
abctl
) expected a JSON response, but received HTML (which begins with 
<doctype...
or 
<html>
). 2. Reverse Proxy / Endpoint Issue: In an Airbyte deployment, this typically occurs when the authentication or token endpoint is misconfigured, unreachable, or intercepting traffic (such as an ingress controller, external reverse proxy, or wrong port/host) and returning an HTML error page (e.g., a 404, 502, or an HTTP Basic Auth dialog) instead of reaching the Airbyte API [Bug Report on login page]. 3. Known Auth & Token Issues in Older Versions: Versions of the Airbyte platform around 
1.8.x
/ Helm chart 
2.0.x
had known issues where 
abctl
failed to resolve tokens, client IDs, or organizations, which prevented retrieving or setting organization emails [Issue 65608; Issue 67581]. Troubleshooting Steps 1. Verify Ingress and Host Configurations If you deployed Airbyte using 
abctl
behind a custom port, reverse proxy, or custom domain (
--host
), make sure the API routes are properly forwarded to the Airbyte service without being blocked or redirected:abctl local statusVerify that Airbyte is healthy and reachable at the listed address [Install and manage local Airbyte instances]. ā—¦ Check if you passed 
--port
or 
--host
during installation: ā—¦ If using non-HTTPS connections with a custom host, ensure cookies/headers are configured appropriately (e.g., 
--insecure-cookies
) [Full abctl reference]. 1. Complete First-Time Web UI Setup If this is a fresh installation, the initial setup may not be complete. Open the Airbyte UI in your browser (e.g., 
http://localhost:8000
), complete the initial registration prompt (enter an email and click Get Started), and then re-run your 
abctl
commands [Issue 65608]. 2. Check Cluster Pod Status If Airbyte services (such as the server, webapp, or bootloader) failed to start, the ingress will return an HTML 502/503 error page. You can check the underlying cluster with `kubectl`:kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get podsInspect logs for any failing pods:kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl logs -l app.kubernetes.io/name=server[Troubleshooting abctl FAQ]. 3. Upgrade to a Newer Chart/Platform Release Auth token generation and organization email issues present in versions around 
1.8.x
were addressed in Airbyte 
2.0.0
and later. Consider upgrading 
abctl
and the local instance:curl -LsfS https://get.airbyte.com | bash - abctl local install[Issue 65608; Issue 67581]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed Yes, you can safely re-run 
abctl local install
with those flags, as 
abctl local install
is designed to both install and update existing installations [Install and manage local Airbyte instances; Full abctl reference]. However, before re-running it, note why you are seeing the 502 Bad Gateway error and the invalid character 
<
error: Why this happens ā€¢ The 502 Bad Gateway error means the 
ingress-nginx
controller is running, but the backend Airbyte services (such as the webapp or server pods) are still starting up, crashed, or not ready to accept traffic. ā€¢ When 
abctl
attempts to connect to the backend to fetch or set tokens and credentials, it receives an HTML error page (the 502 page from Nginx, starting with 
<html>
) instead of a JSON response. This triggers the error: 
unable to decode token request: invalid character '<' looking for beginning of value
. Recommended Steps 1. Check if the services are still initializing or failing Depending on your machine's hardware and network speed, an install or upgrade can take some time [Install and manage local Airbyte instances]. Check the status of your Kubernetes pods first to see what is failing or taking time:kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods[Troubleshooting abctl FAQ]kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl logs pod-name ā—¦ If pods show 
CrashLoopBackOff
or 
Error
, inspect their logs (for example, the bootloader or server): 1. Re-run the install command If you originally deployed with custom parameters (like 
--host
, 
--insecure-cookies
, or 
--low-resource-mode
), running a plain 
abctl local install
during the upgrade may have overwritten those configurations.Re-running the upgrade while preserving your required flags is the proper approach:abctl local install --host [your airbyte instance] --no-browser --insecure-cookies --low-resource-mode[Full abctl reference; Using an EC2 Instance with abctl] 2. Check the instance status Once the command finishes and all containers have finished launching, confirm the status of the deployment:abctl local status[Install and manage local Airbyte instances] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed A 502 Bad Gateway error means that the NGINX Ingress Controller is up and running, but the backend Airbyte service (such as the Airbyte server or webapp) is either still starting up, failing its health checks, or crashing. Here is how you can inspect and resolve the issue: 1. Check the Pod Status During an install or upgrade, Airbyte services (such as the bootloader, database migrations, and server) can take several minutes to fully start up and become healthy [Install and manage local Airbyte instances]. Use 
kubectl
pointing to your 
abctl
kubeconfig to inspect the state of the pods:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods
[Troubleshooting abctl FAQ] ā€¢ If the pods (especially 
airbyte-server
or 
airbyte-webapp
) are in 
ContainerCreating
, 
Pending
, or 
0/1 Running
status, they are still initializing. Wait a few moments and check again. ā€¢ If you see 
CrashLoopBackOff
or 
Error
, inspect the logs of that specific pod to see what failed:kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl logs pod-name 2. Check the Helm Chart Status Check the status reported by `abctl`:
Copy code
abctl local status
[Install and manage local Airbyte instances] Ensure that the Helm chart status reports 
deployed
rather than 
failed
. 3. Known Ingress Target Issue on Airbyte Upgrades In some versions of 
abctl
(such as 
v0.30.1
installing Airbyte 
v1.8.x
), there is a known issue where the ingress was misconfigured to route traffic to 
airbyte-abctl-airbyte-webapp-svc
instead of 
airbyte-abctl-airbyte-server-svc
, leading to 503/502 errors [Airbyte Issue #65539]. You can check if the ingress endpoints are correctly pointing to a live service by running:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl describe ingress ingress-abctl
[Airbyte Issue #65539] 4. Restart Deployments If the pods appear hung or unresponsive, you can attempt to restart the Kubernetes deployments using `abctl`:
Copy code
abctl local deployments --restart
[Install and manage local Airbyte instances] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed This error (
stat /root/.airbyte/abctl/abctl.kubeconfig: no such file or directory
) typically occurs under one of the following conditions: 1. Permission or User Context Mismatch According to the Airbyte documentation, this error happens when 
abctl
does not have permission to create files and folders in your system [Could not Create REST Config]. Additionally, state data (such as the cluster data and 
abctl.kubeconfig
) is stored in the home directory at 
~/.airbyte/abctl/
[Install abctl]. If you previously ran commands as a standard non-root user (e.g., in 
/home/<username>/.airbyte/...
) and are now running commands with 
sudo
or as the 
root
user (or vice versa), 
abctl
or 
kubectl
will look in 
/root/
instead of your actual user directory. ā€¢ Check which user originally ran the installation and ensure you are running subsequent commands as that same user (or adjust your 
--kubeconfig
path to point to your user's home directory instead of 
/root/
). 2. Communication Failure with the Local Cluster If 
abctl
failed to export or initialize the Kubernetes configuration from Docker/Kind, it cannot generate the 
abctl.kubeconfig
file [Issue 70441]. To resolve cluster communication issues: 1. Try uninstalling the local instance:abctl local uninstall_(Note: Your data will persist between uninstall and install commands) [Issue 70441]._ 2. Reinstall Airbyte:abctl local installInclude any required flags you originally used (such as 
--host
, 
--insecure-cookies
, or 
--low-resource-mode
) [Full abctl reference]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai as you advised for 502 error I excuted: kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods and got: error: stat /root/.airbyte/abctl/abctl.kubeconfig: no such file or directory
k
Thinking completed This error occurs because 
kubectl
is looking for the configuration file in 
/root/.airbyte/abctl/abctl.kubeconfig
, but the file is not there. This happens for one of two reasons: 1. User Account / Sudo Mismatch Airbyte state data (including 
abctl.kubeconfig
) is stored in the home directory at 
~/.airbyte/abctl/
[Customize the install location]. If you ran 
abctl local install
as a regular user (for example, 
ubuntu
or your normal login account), the file will be located at 
/home/<your-username>/.airbyte/abctl/abctl.kubeconfig
, not in 
/root/
. Running 
kubectl
as 
root
(or with 
sudo
) causes 
~
to resolve to 
/root/
. ā€¢ Run the command without 
sudo
under the regular user account that originally installed Airbyte. ā€¢ Alternatively, provide the explicit path to your user directory:kubectl --kubeconfig /home/your-username/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods 2. Permissions or Cluster Initialization Issue If you did run 
abctl
as 
root
and the file is still missing: ā€¢ This error occurs when 
abctl
does not have sufficient permissions to create files and folders in the filesystem [Could not Create REST Config]. ā€¢ It also happens if the underlying Kubernetes cluster failed to export the configuration properly during the install process [Issue 70441]. When this happens, the recommended recovery step is to uninstall and reinstall the local cluster: 1. Run uninstall to reset the local cluster state (your Airbyte data persists between these commands) [Issue 70441]:abctl local uninstall 2. Re-run the installation command with your flags [Full abctl reference]:abctl local install --host [your airbyte instance] --no-browser --insecure-cookies --low-resource-mode šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai outside the docker I can see this path ~/.airbyte/abctl/abctl.kubeconfig maybe the name space is wrong?
k
Thinking completed The namespace is not wrong. By default, 
abctl
always creates and uses the namespace 
airbyte-abctl
[Issue 62468; Issue 65574]. If 
kubectl
returned the error 
stat /root/.airbyte/abctl/abctl.kubeconfig: no such file or directory
, it failed before even checking the namespace because it could not locate the kubeconfig file itself. This happens because the command was executed in a shell running as the 
root
user (or using 
sudo
). In that environment, 
~
expands to 
/root
, whereas your 
abctl.kubeconfig
file resides in your non-root user's home directory (such as 
/home/<username>/.airbyte/abctl/abctl.kubeconfig
) [Customize the install location]. How to Fix Run the command from outside Docker as your normal user account (without 
sudo
):
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods
Or, specify the full absolute path to your user's home directory:
Copy code
kubectl --kubeconfig /home/<your-username>/.airbyte/abctl/abctl.kubeconfig --namespace airbyte-abctl get pods
Alternatively, you can inspect all namespaces to see what exists in the cluster:
Copy code
kubectl --kubeconfig /home/<your-username>/.airbyte/abctl/abctl.kubeconfig get pods -A
šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed Yes, this output helps identify the problem. All core Airbyte backend pods (
airbyte-abctl-server
, 
airbyte-db-0
, etc.) are healthy and in the 
Running
(or 
Completed
for bootloader) state. Notice that there is no 
webapp
pod running. The Cause of the 502/503 Error Starting in Airbyte 1.7 and 1.8, the 
webapp
service was merged into 
server
, and the standalone 
airbyte-webapp
pod/image was removed [Update ingress for version 1.7 and later]. In certain versions of 
abctl
(such as 
v0.30.1
installing Airbyte 
v1.8.x
), there is a known issue where the generated ingress rule continues pointing to the old, non-existent service 
airbyte-abctl-airbyte-webapp-svc
instead of routing to 
airbyte-abctl-airbyte-server-svc
[abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. Because the ingress tries to send your browser traffic to a backend service that does not exist, NGINX immediately returns a 502 or 503 error [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. How to Confirm Run this command inside your control plane node:
Copy code
kubectl describe ingress ingress-abctl -n airbyte-abctl
[abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target] If you see an error like:
Copy code
Error: services "airbyte-abctl-airbyte-webapp-svc" not found
it confirms that the ingress is trying to forward traffic to the deprecated webapp service [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. How to Fix You have two options to resolve this: Option 1: Edit the Ingress Resource Directly Edit the ingress rule to direct traffic to 
airbyte-abctl-airbyte-server-svc
[abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]:
Copy code
kubectl edit ingress ingress-abctl -n airbyte-abctl
In the editor, find the default rule under 
paths
and change the backend service name from:
Copy code
service:
  name: airbyte-abctl-airbyte-webapp-svc
to:
Copy code
service:
  name: airbyte-abctl-airbyte-server-svc
Save and exit. The ingress should immediately route traffic to the running server pod [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. Option 2: Provide the Legacy Webapp in values.yaml Another workaround is to explicitly re-enable the legacy webapp image in your 
values.yaml
and re-run the install [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]:
Copy code
webapp:
  enabled: true
  image:
    tag: 1.7.8
    repository: airbyte/webapp
    pullPolicy: IfNotPresent
Then pass that configuration file with 
--values
during 
abctl local install
[abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed Based on the 
kubectl describe ingress
output, there are two key findings: 1. Why connector-builder-server-svc shows "not found" The ingress rule for 
/api/v1/connector_builder
is failing with: 
<error: services "airbyte-abctl-airbyte-connector-builder-server-svc" not found>
This occurs because you installed Airbyte using the 
--low-resource-mode
flag. When Airbyte is installed in low-resource mode, the Connector Builder service is intentionally turned off to conserve system resources [Disabled in low-resource mode; The connector builder service doesn't exist]. (Additionally, in Airbyte 2.1, the 
connector-builder-server
was replaced by the manifest server [Airbyte 2.1 Release Notes]). 2. Why you are still getting a 502 error on the root URL Notice that the root path 
/
is correctly pointing to the running server:
Copy code
/   airbyte-abctl-airbyte-server-svc:http (10.244.0.13:8001)
Because the Ingress controller successfully resolved the IP and port of 
airbyte-server-svc
, the 502 Bad Gateway is coming from the 
airbyte-abctl-server
application itself refusing or failing to handle requests on port 
8001
. How to Fix Step 1: Check the server pod logs Inspect the logs of your server pod to see why it is returning an error or failing health checks:
Copy code
kubectl logs -n airbyte-abctl deployment/airbyte-abctl-server
Step 2: Remove the missing Connector Builder route from Ingress Because 
connector-builder-server-svc
does not exist in low-resource mode, it can cause NGINX configuration sync issues. You can remove the 
/api/v1/connector_builder
path blocks: 1. Edit the ingress:kubectl edit ingress ingress-abctl -n airbyte-abctl 2. Remove the path blocks referencing `airbyte-abctl-airbyte-connector-builder-server-svc`: - backend: service: name: airbyte-abctl-airbyte-connector-builder-server-svc port: name: http path: /api/v1/connector_builder pathType: PrefixKeep only the 
/
path routing to 
airbyte-abctl-airbyte-server-svc
. 3. Save and exit. Step 3: (Optional) Re-deploy without --low-resource-mode If you need to use the Connector Builder and have sufficient hardware resources available, re-run the installation without the 
--low-resource-mode
flag:
Copy code
abctl local install --host airbyte-us3.transperfect.com --no-browser --insecure-cookies
[Disabled in low-resource mode; The connector builder service doesn't exist] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai from the logs: 2026-09-17T150243.777669050Z main ERROR Log4j API could not find a logging provider.
k
Thinking completed The knowledge sources do not explicitly mention a direct fix for the error message:
Copy code
ERROR Log4j API could not find a logging provider.
However, based on the provided logs and GitHub issues: 1. It is an anomaly seen during migrations/upgrades: This exact log line has been reported in other GitHub issues during version upgrades and migrations (for example, upgrading Helm charts from older releases to version 2.0.x) [Source check_connection hangs; Syncs doesn't start after Airbyte upgrade]. 2. It indicates a missing or conflicting logging implementation: In Java applications, this error occurs when the Log4j2 API is called, but no matching backend/provider (such as Log4j Core or an SLF4J binding) is initialized or configured properly in the classpath or logging configuration. 3. The server may be stalled or failing further down: In similar upgrade scenarios where this line appears, the server may either hang during initialization (producing zero output after startup) or fail to process incoming requests properly [Source check_connection hangs]. Recommended Next Steps ā€¢ Check subsequent logs: Check if the server pod printed additional logs after this message by following the live logs:kubectl logs -n airbyte-abctl deployment/airbyte-abctl-server --tail=100 -f ā€¢ Verify database migration status: Check the logs of the bootloader pod to ensure all database migrations finished cleanly:kubectl logs -n airbyte-abctl airbyte-abctl-bootloader ā€¢ Restart the server pod: If the server process hung during initialization, restarting the deployment can sometimes allow it to initialize cleanly:kubectl rollout restart deployment/airbyte-abctl-server -n airbyte-abctl šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai root@airbyte-abctl-control-plane:~# kubectl edit ingress ingress-abctl -n airbyte-abctl error: unable to launch the editor "vi"
k
Thinking completed The knowledge sources do not explicitly mention the error 
error: unable to launch the editor "vi"
. However, this is a standard Linux/Kubernetes environment error indicating that the control-plane container does not have 
vi
(or any default text editor) installed in its filesystem. You can resolve this using one of the following methods: Option 1: Install a Text Editor (Inside the Container) Since you are logged into 
airbyte-abctl-control-plane
as 
root
, update the package manager and install 
nano
or `vim`:
Copy code
apt-get update && apt-get install -y nano
Then run 
kubectl edit
specifying the editor in the environment variable:
Copy code
KUBE_EDITOR=nano kubectl edit ingress ingress-abctl -n airbyte-abctl
Option 2: Run kubectl from Your Host Machine (Outside Docker) Instead of running 
kubectl
from inside the control-plane container, execute it from your host terminal where your default editor exists. Point it to the 
abctl.kubeconfig
file [Troubleshooting abctl FAQ]:
Copy code
kubectl --kubeconfig ~/.airbyte/abctl/abctl.kubeconfig edit ingress ingress-abctl -n airbyte-abctl
(If your host user is different, replace 
~
with 
/home/<your-username>
.) Option 3: Export, Edit, and Apply via YAML If you cannot install an editor inside the container, you can dump the manifest, modify it, and apply it back: 1. Export the current Ingress to a YAML file:kubectl get ingress ingress-abctl -n airbyte-abctl -o yaml > ingress.yaml 2. Modify the file on your host machine (or using 
sed
), then apply the changes back:kubectl apply -f ingress.yaml šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed Based on your 
abctl status
output: 1. Both Helm charts are properly deployed: 
airbyte-abctl
(version 2.3.0) and 
ingress-nginx
(version 1.15.1) report 
deployed
. 2. The Kubeconfig path: Notice that the kubeconfig is stored on your host at 
/home/glpd/.airbyte/abctl/abctl.kubeconfig
. Because the Helm chart and Ingress controller are running, the 502 Bad Gateway error means 
ingress-nginx
is working, but it cannot get a successful response from the backend Airbyte service [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. Key Causes & How to Fix 1. The Ingress Routes to a Non-Existent Connector Builder Service From your earlier 
kubectl describe ingress
, the ingress rules include:
Copy code
/api/v1/connector_builder   airbyte-abctl-airbyte-connector-builder-server-svc:http (<error: services "airbyte-abctl-airbyte-connector-builder-server-svc" not found>)
Because you installed with 
--low-resource-mode
, the Connector Builder service is disabled [The connector builder service doesn't exist]. (Additionally, in Airbyte 2.1+, the 
connector-builder-server
was deprecated/replaced [Airbyte 2.1 Release Notes]). If you want to use the full feature set without routing errors to missing services, reinstall without `--low-resource-mode`:
Copy code
abctl local install --host airbyte-us3.transperfect.com --no-browser --insecure-cookies
2. The Server Application is Still Stalled or Starting In the logs earlier, the server printed 
Log4j API could not find a logging provider
, which has been observed in version upgrade issues when the application hangs or stalls during startup [Source check_connection hangs]. Run the following command directly from your host machine (as your 
glpd
user, outside of Docker) to check if the server is responding or still throwing errors [Troubleshooting abctl FAQ]:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs -l app.kubernetes.io/name=server --tail=100
3. Restart the Local Deployments If the pods got into a stalled state after the chart upgrade, trigger a restart using 
abctl
[Install and manage local Airbyte instances]:
Copy code
abctl local deployments --restart
šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai I made that: If you want to use the full feature set without routing errors to missing services, reinstall without 
--low-resource-mode
but keep getting 502 error
k
Thinking completed The knowledge sources do not explicitly explain why a 502 error persists after removing the 
--low-resource-mode
flag during an upgrade to chart/app version 2.3.0. However, based on the previous symptoms and logs you provided, here is why this is occurring and how to pinpoint the issue: 1. Ingress Target Change in 2.x In Airbyte 2.x, the backend services were restructured (for example, 
connector-builder-server
was replaced by 
manifest-server
, and the standalone 
webapp
was removed) [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. If the Ingress is still configured with an old or non-existent backend target, NGINX cannot route traffic and will return a 502/503 error [abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. Check what backend services are currently defined and whether any report `error: services ... not found`:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig describe ingress ingress-abctl -n airbyte-abctl
[abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target] Ensure that the root path 
/
is targeting 
airbyte-abctl-airbyte-server-svc
and that its endpoints are resolving properly [Update ingress for version 1.7 and later; abctl v0.30.1 installs Airbyte v1.8.1 with incorrect ingress target]. 2. Check the Server Pod's Startup and Readiness The earlier log line:
Copy code
ERROR Log4j API could not find a logging provider.
has been documented in upgrade issues where the 
server
pod stalls or hangs during startup [Source check_connection hangs; Syncs doesn't start after Airbyte upgrade]. If the server process hangs or crashes, its port (8001) will not accept traffic, causing NGINX to return a 502 Bad Gateway. Run this command from your host machine to see the server pod's recent activity:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs deployment/airbyte-abctl-server --tail=200
Also check the pod's readiness probe events to see why NGINX might be rejecting it:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl describe pod -l app.kubernetes.io/name=server
3. Verify Database Migrations Completed If database migrations did not complete during the upgrade, the server will not start serving traffic. Inspect the bootloader pod logs:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs airbyte-abctl-bootloader
Check whether the bootloader finished with successful Flyway migrations or encountered migration errors. 4. Restart Deployments If the services are stuck in a deadlocked or hung initialization state following the upgrade, restart the deployments via `abctl`:
Copy code
abctl local deployments --restart
[Install and manage local Airbyte instances] šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed The error 
-bash: kubectl: command not found
means that 
kubectl
is not installed on your host machine. As noted in the documentation, 
abctl
does not install 
kubectl
automatically; if you want to use standard tools like 
kubectl
to interact directly with the cluster, you must install them yourself [Troubleshooting abctl FAQ]. You can check the logs without installing 
kubectl
on your host using either of these approaches: Option 1: Run kubectl Inside the Kind Node (via Docker) Since 
kubectl
is already present inside the 
airbyte-abctl-control-plane
container, you can execute the command through `docker exec`:
Copy code
docker exec -it airbyte-abctl-control-plane kubectl -n airbyte-abctl logs deployment/airbyte-abctl-server --tail=200
To see details about why the pod might not be ready, run:
Copy code
docker exec -it airbyte-abctl-control-plane kubectl -n airbyte-abctl describe pod -l app.kubernetes.io/name=server
Option 2: Install kubectl on Your Host Machine If you prefer running commands directly on your host, you can download the 
kubectl
binary (for Linux x86_64):
Copy code
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/
Once installed, your original command will work [Troubleshooting abctl FAQ]:
Copy code
kubectl --kubeconfig /home/glpd/.airbyte/abctl/abctl.kubeconfig -n airbyte-abctl logs deployment/airbyte-abctl-server --tail=200
šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai that's not an option, kubectl is used in side of docker and it work for another instances so far
k
Thinking completed Understood. Since 
kubectl
is available inside the control plane container, you can run all inspection commands directly from inside that container (where you ran them earlier):
Copy code
kubectl -n airbyte-abctl logs deployment/airbyte-abctl-server --tail=200
To see why the pod or its endpoints might not be responding or passing health checks, check the pod's status and events:
Copy code
kubectl -n airbyte-abctl describe pod -l app.kubernetes.io/name=server
Also check the bootloader logs to verify whether database migrations succeeded during the upgrade:
Copy code
kubectl -n airbyte-abctl logs airbyte-abctl-bootloader
Please share the output of the server logs or events so we can identify what is causing the server to return the 502 error. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thinking completed The knowledge sources do not explicitly mention the root cause or a specific resolution for the error:
Copy code
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied
However, analyzing the log output reveals why you are encountering the 502 error: What Is Happening 1. The Server Process Did Not Start: The logs end immediately after unsetting the environment variables. There is no 
Micronaut
startup banner, no HTTP listener binding on port 
8001
, and no application initialization. 2. Container Entrypoint Failure: The entrypoint script inside the container attempted to set up the system certificate trust store (
update-ca-trust
/ symbolic linking under 
/etc/pki/ca-trust/...
), failed due to 
Permission denied
(the container runs as a non-root user without write access to 
/etc/pki
), and terminated before executing the Java server application. 3. Resulting 502 Bad Gateway: Because the Airbyte server process failed to launch, nothing is listening on port 
8001
. The NGINX Ingress controller attempts to forward your web request to 
10.244.0.13:8001
, gets a connection refused, and returns 502 Bad Gateway. Recommended Steps to Investigate and Resolve 1. Check the Pod Status and Termination Reason Inside the control plane container, inspect the pod's exact state, restart counts, and exit code:
Copy code
kubectl -n airbyte-abctl describe pod -l app.kubernetes.io/name=server
Look at the Containers -> State (or Last State) section to see the exit code and termination reason. 2. Verify Database Bootloader Completion Ensure that the database migration did not leave the system in an incomplete state before the server started:
Copy code
kubectl -n airbyte-abctl logs airbyte-abctl-bootloader
3. Attempt a Clean Re-deployment If the issue stems from container security contexts or corrupted local volumes after an in-place upgrade, uninstalling and reinstalling resets the Kubernetes deployment resources while preserving your sync data [Issue 70441]: 1. Run uninstall:abctl local uninstall 2. Reinstall with your required parameters:abctl local install --host airbyte-us3.transperfect.com --no-browser --insecure-cookies šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai from the first command you sent: Type Status PodReadyToStartContainers True Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-ttjq7: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 12m default-scheduler Successfully assigned airbyte-abctl/airbyte-abctl-server-598456b858-btqkq to airbyte-abctl-control-plane Normal Pulling 12m kubelet Pulling image "airbyte/server:2.3.0" Normal Pulled 11m kubelet Successfully pulled image "airbyte/server:2.3.0" in 3.635s (40.273s including waiting). Image size: 506273057 bytes. Normal Created 11m kubelet Created container: airbyte-server-container Normal Started 11m kubelet Started container airbyte-server-container Warning Unhealthy 11m kubelet Readiness probe failed: Get "10.244.0.14/api/v1/health": dial tcp 10.244.0.148001 connect: connection refused
k
Thinking completed This event explains the exact cause of the 502 error:
Copy code
Warning  Unhealthy  11m   kubelet  Readiness probe failed: Get "http://10.244.0.14:8001/api/v1/health": dial tcp 10.244.0.14:8001: connect: connection refused
What This Means ā€¢ Connection refused on port 8001: The readiness probe fails because nothing is listening on port 
8001
inside the container [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts; Kubernetes check connection issues]. ā€¢ 502 Bad Gateway: Because the Airbyte server process did not bind to port 
8001
or failed during initialization, the NGINX Ingress controller cannot connect to the backend pod and returns 
502 Bad Gateway
. Combined with your earlier log output:
Copy code
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied
Unsetting empty environment variable '...'
The server startup entrypoint either halted or stalled before the Java/Micronaut application could start and open port 
8001
. What to Check Next 1. Check if the Server Process Stalled or Exited Run the following inside the control-plane container to see if the Java process is actually running:kubectl -n airbyte-abctl exec -it deployment/airbyte-abctl-server -- ps auxIf no Java/server process is listed, the entrypoint script terminated unexpectedly. 2. Check the Bootloader Logs The server often fails to initialize or start its HTTP listeners if database migrations did not complete cleanly during the upgrade. Check the bootloader container logs [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]:kubectl -n airbyte-abctl logs airbyte-abctl-bootloaderEnsure the bootloader finished with 
Finished bootstrapping Airbyte environment
rather than an error or migration failure [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. 3. Check Database Health Verify that the database pod is healthy and accepting connections:kubectl -n airbyte-abctl logs airbyte-db-0 --tail=50 4. Restart the Server Pod If the startup sequence hung due to a transient initialization deadlock, triggering a restart of the deployment can allow the process to initialize cleanly:kubectl -n airbyte-abctl rollout restart deployment/airbyte-abctl-server šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai it is not a public URL I'm trying to access via the machine IP, the url are at localhost in windows just to allow us to access via webbrowser
k
Thinking completed Based on the provided knowledge sources, here is what you need to know about accessing Airbyte via a machine IP or `localhost`: 1. The Root Cause of the 502 Error Still Applies Even though you are accessing Airbyte via the machine IP or 
localhost
, the 502 Bad Gateway error is not caused by your browser's network route. As shown by your Kubernetes events:
Copy code
Readiness probe failed: Get "http://10.244.0.14:8001/api/v1/health": dial tcp 10.244.0.14:8001: connect: connection refused
The internal 
airbyte-server
application inside the container has failed to start or open port 
8001
[Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts; Kubernetes check connection issues]. Because the internal server is refusing connections, NGINX will return a 502 error regardless of whether you access it via a domain name, an IP address, or 
localhost
. 2. How abctl Ingress Rules Handle Hosts vs. Localhost ā€¢ By default, 
abctl
only configures ingress rules for 
localhost
(allowing access at 
http://localhost:8000
) [Full abctl reference; Using an EC2 Instance with abctl]. ā€¢ When you pass 
--host [HOSTNAME]
, 
abctl
sets up ingress routing for that specific host/FQDN [Full abctl reference; Using an EC2 Instance with abctl]. From your earlier 
kubectl describe ingress
output, your cluster configured rules for: ā—¦ 
airbyte-us3.transperfect.com
ā—¦ 
localhost
ā—¦ 
host.docker.internal
ā€¢ If you access the web interface directly using an IP address instead of 
localhost
or the configured hostname, NGINX may not match the host header unless the ingress is configured for all incoming traffic (which is the default when omitting 
--host
) [Full abctl reference]. ā€¢ When accessing over HTTP rather than HTTPS (especially across machines or via an IP address), you must pass the 
--insecure-cookies
flag to prevent authentication cookie failures [Make sure you have disabled secure cookies; Using an EC2 Instance with abctl]. Recommended Next Steps 1. Resolve the server process failure first Check whether the bootloader finished properly or whether the database migrations failed, preventing the server from starting [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]:kubectl -n airbyte-abctl logs airbyte-abctl-bootloaderCheck if the database pod is healthy [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]:kubectl -n airbyte-abctl logs airbyte-db-0 --tail=50 2. If accessing only locally / via IP without a dedicated hostname If you do not need the specific FQDN and want 
abctl
to allow all incoming traffic on port 8000, omit the 
--host
flag and keep 
--insecure-cookies
[Full abctl reference; Using an EC2 Instance with abctl]:abctl local install --no-browser --insecure-cookies šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai helth check: root@airbyte-abctl-control-plane:/# kubectl -n airbyte-abctl logs airbyte-db-0 --tail=50 PostgreSQL Database directory appears to contain a database; Skipping initialization 2026-09-17 153921.636 UTC [17] LOG: starting PostgreSQL 13.23 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit 2026-09-17 153921.636 UTC [17] LOG: listening on IPv4 address "0.0.0.0", port 5432 2026-09-17 153921.636 UTC [17] LOG: listening on IPv6 address "::", port 5432 2026-09-17 153921.639 UTC [17] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-09-17 153921.642 UTC [25] LOG: database system was interrupted; last known up at 2026-09-17 153155 UTC 2026-09-17 153921.671 UTC [25] LOG: database system was not properly shut down; automatic recovery in progress 2026-09-17 153921.672 UTC [25] LOG: redo starts at 349/DE444720 2026-09-17 153921.694 UTC [25] LOG: invalid record length at 349/DE9A7558: wanted 24, got 0 2026-09-17 153921.694 UTC [25] LOG: redo done at 349/DE9A7530 2026-09-17 153921.732 UTC [17] LOG: database system is ready to accept connections 2026-09-17 154008.245 UTC [44] ERROR: database "temporal" already exists 2026-09-17 154008.245 UTC [44] STATEMENT: CREATE DATABASE "temporal" 2026-09-17 154008.347 UTC [47] ERROR: database "temporal_visibility" already exists 2026-09-17 154008.347 UTC [47] STATEMENT: CREATE DATABASE "temporal_visibility" 2026-09-17 154008.621 UTC [61] ERROR: duplicate key value violates unique constraint "namespaces_pkey" 2026-09-17 154008.621 UTC [61] DETAIL: Key (partition_id, id)=(54321, \x32049b68787240948e63d0dd59896a83) already exists. 2026-09-17 154008.621 UTC [61] STATEMENT: INSERT INTO namespaces (partition_id, id, name, is_global, data, data_encoding, notification_version) VALUES($1, $2, $3, $4, $5, $6, $7)
k
Thinking completed Based on your PostgreSQL logs, here is what is happening: 1. The Database Is Healthy and Ready PostgreSQL recovered cleanly and is accepting connections:
Copy code
2026-09-17 15:39:21.732 UTC [17] LOG: database system is ready to accept connections
2. The Temporal Database Errors Are Normal for Re-deploys / Upgrades You can see these log lines:
Copy code
ERROR: database "temporal" already exists
ERROR: database "temporal_visibility" already exists
ERROR: duplicate key value violates unique constraint "namespaces_pkey"
DETAIL: Key (partition_id, id)=(54321, \x32049b68787240948e63d0dd59896a83) already exists.
ā€¢ When Airbyte starts up or upgrades, the Temporal auto-setup scripts attempt to create the 
temporal
and 
temporal_visibility
databases and insert default namespace definitions [Airbyte-temporal started failed after execute docker-compose up; Airbyte Temporal context deadline exceeded on eks]. ā€¢ Since this is an existing installation, those databases and the 
namespaces_pkey
record already exist [Airbyte-temporal started failed after execute docker-compose up; Airbyte Temporal context deadline exceeded on eks]. In a working environment, this duplicate key error routinely occurs during initialization and is safely handled [Airbyte Temporal context deadline exceeded on eks]. What to Check Next Because PostgreSQL is accepting connections and Temporal has finished attempting schema creation, the database is not blocking Airbyte. The issue remains with the 
airbyte-abctl-server
 container failing its readiness probe (
connect: connection refused
on port 
8001
) [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. To find the actual cause of the server failure: 1. Check the bootloader pod logs to confirm all Airbyte configuration and schema migrations completed successfully:kubectl -n airbyte-abctl logs airbyte-abctl-bootloaderLook for 
Finished bootstrapping Airbyte environment
or any fatal Flyway migration error [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. 2. Check whether the Java server process is running inside the server pod:kubectl -n airbyte-abctl exec deployment/airbyte-abctl-server -- ps auxIf no Java process is listed, the server entrypoint script aborted before launching the application. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai error: error from server (NotFound): pods "airbyte-abctl-bootloaderLook" not found in namespace "airbyte-abctl"
k
Thinking completed The word "Look" was accidentally appended to the pod name in your command, causing Kubernetes to look for a pod named 
airbyte-abctl-bootloaderLook
instead of 
airbyte-abctl-bootloader
. From your earlier 
kubectl get pods -n airbyte-abctl
output, the pod name is 
airbyte-abctl-bootloader
. Run the command with the exact pod name:
Copy code
kubectl -n airbyte-abctl logs airbyte-abctl-bootloader
Check the bottom of those logs to see if it ended with 
Finished bootstrapping Airbyte environment
or if there was a database migration failure [Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai root@airbyte-abctl-control-plane:/# kubectl -n airbyte-abctl logs airbyte-abctl-bootloader ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied
k
Thinking completed The knowledge sources do not explicitly explain the cause of or provide an official solution for the specific error:
Copy code
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied
However, comparing this output with your previous server pod logs reveals the root cause of the entire failure (including the 502 Bad Gateway error): Root Cause 1. Both the Bootloader and Server Failed at the Same Step: ā—¦ Both 
airbyte-abctl-server
and 
airbyte-abctl-bootloader
execute an entrypoint script that attempts to update the system CA certificates (
update-ca-trust
/ creating symlinks in 
/etc/pki/ca-trust/...
). ā—¦ The containers are running under a non-root user that lacks write permissions to 
/etc/pki/ca-trust/extracted/pem/directory-hash/
. 1. Bootloader Did Not Run Database Migrations: ā—¦ The bootloader pod exited immediately on this permission failure without running any Flyway migrations, database initialization, or bootstrapping tasks. ā—¦ When the bootloader fails or does not complete its bootstrap tasks, the deployment cannot proceed properly, and subsequent services fail [Troubleshoot Deploy Common Errors; Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. 1. Server Cannot Start: ā—¦ Because the server pod encounters the exact same script failure, its Java/Micronaut process never starts, nothing listens on port 8001, and the readiness probe fails with 
connection refused
[Deploy Kubernetes(EKS): Unable to launch airbyte using helm charts]. ā—¦ As a result, NGINX returns 502 Bad Gateway. Recommended Workarounds and Next Steps 1. Perform a Clean Local Reinstall Since this issue often occurs when upgrading existing Kind nodes where permissions on underlying container overlays or security contexts become mismatched, performing an uninstall and reinstall will recreate the cluster resources cleanly [Github Issue: Cluster communication failure]:abctl local uninstall_(Note: Airbyte retains your local sync data between uninstall and install commands) [Github Issue: Cluster communication failure]._Then run the install command again:abctl local install --host airbyte-us3.transperfect.com --no-browser --insecure-cookies 2. Check for Security Context / Custom Root CA Settings If you have mounted custom CA certificates or configured custom security contexts / volume mounts in a 
values.yaml
file, the entrypoint script may be triggered to rebuild certificate stores without the necessary write permissions. Ensure that pods have appropriate permissions or that custom truststore files are mounted directly rather than invoking system trust updates as non-root. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai I already re-installa and install again before
k
Thinking completed The knowledge sources do not explicitly provide a documented resolution or official bug fix for the persistent error:
Copy code
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-certificates.crt': Permission denied
ln: failed to create symbolic link '/etc/pki/ca-trust/extracted/pem/directory-hash/ca-bundle.crt': Permission denied
However, based on the information in the knowledge sources regarding permissions, volumes, and 
abctl
persistence: Why a Standard abctl local uninstall and install Did Not Fix It When you run 
abctl local uninstall
, Airbyte intentionally retains your persistent volumes and local data directories on the host so that configurations and state are not lost [Issue 70441]. In 
abctl
, these underlying persistent volume directories are stored on the host under 
~/.airbyte/abctl/data/
[permission denied when try to set up duckdb destination; Issue 75527]. If file ownership or permissions on these directories became mismatched or restricted during the version upgrade, reinstalling the cluster will continue mounting the same restricted directories into the pods [Permission issue while installing Airbyte with abctl; permission denied when try to set up duckdb destination]. Potential Workarounds 1. Adjust Host Directory Permissions For permission issues on volumes mapped by 
abctl
, adjusting the permissions on the host directory backing the Kubernetes persistent volumes can resolve container write failures [permission denied when try to set up duckdb destination]:sudo chmod -R 777 ~/.airbyte/abctl/data/_(Or 
/home/glpd/.airbyte/abctl/data/
)_. After adjusting permissions, try restarting the deployments:abctl local deployments --restart[Install and manage local Airbyte instances] 2. Check for Custom CA Certificates or Values Overrides The 
ln: ... ca-certificates.crt: Permission denied
error indicates that an entrypoint script is attempting to run 
update-ca-trust
inside the container. If you passed custom Helm values (via 
--values
) that inject custom root certificates or mount paths into 
/etc/pki/
or 
/usr/local/share/ca-certificates/
, the non-root container user will not have permissions to modify system PKI symlinks. Check if any certificate injection settings are active in your deployment. 3. Complete Fresh Reset (Data Loss Warning) If there is corrupted state or an incompatible schema migration stuck in the persistent volume from an earlier version, a complete teardown requires removing the persisted cluster data. _(Note: This deletes local Airbyte databases and configurations, so back up any necessary data first)_:abctl local uninstall --persistedThen perform a clean install:abctl local install --host airbyte-us3.transperfect.com --no-browser --insecure-cookies šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Open in Slack
PreviousNext
Powered by